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The National Aeronautics and Space Administration is conducting a series of flight tests 
intended to support the reduction of barriers that prevent unmanned aircraft from flying 
without the required waivers from the Federal Aviation Administration. The most recent 
testing supported two separate test configurations. The first investigated the timing of Detect 
and Avoid (DAA) alerting thresholds using a radar-equipped unmanned vehicle and 
multiple live intruders flown at varying encounter geometries. The second configuration 
included a surrogate unmanned vehicle (flown from a ground control station, with a safety 
pilot on board) flying a mission in a virtual air traffic control airspace sector using research 
pilot displays and DAA advisories to maintain separation from live and virtual aircraft. The 
test was conducted over a seven-week span in the summer of 2015. The data from over 100 
encounter sorties will be used to inform the RTCA Phase 1 Detect and Avoid and Command 
and Control Minimum Operating Performance Standards (MOPS) intended to be completed 
by the summer of 2016. Follow-on flight-testing is planned for the spring of 2016 to capture 
remaining encounters and support validation of the MOPS. 


Nomenclature 
ADS-B = Automatic Dependent Surveillance - Broadcast 
C2 = Command and Control 
DAA = Detect and Avoid 
FAA = Federal Aviation Administration 
GCS = Ground Control Station 
LVC = Live, Virtual, Constructive describing the simulation environment 
MOPS = Minimum Operating Performance Standards 
NAS = National Airspace System 
NASA = National Aeronautics and Space Administration 
NM = Nautical Miles 
TCAS = Traffic Alert and Collision Avoidance System 
UAS = Unmanned Aircraft System 
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I. Introduction 


HERE has been a tremendous increase in the interest of flying unmanned aircraft safely in the National 

Airspace System (NAS) in recent years.! The application of unmanned aircraft to perform national security, 
defense, scientific, and emergency management are driving the critical need for less restrictive access by Unmanned 
Aircraft Systems (UAS) to the NAS. UAS represent a new capability that will provide a variety of services in the 
government (public) and commercial (civil) aviation sectors. The growth of this potential industry has not yet been 
realized due in part to the lack of a common understanding of what is required to safely operate UAS in the NAS.” 
In response, the Federal Aviation Administration (FAA) has been mandated to “develop a comprehensive plan to 
safely accelerate the integration of civil unmanned aircraft systems (UAS) into the national airspace system”.*? While 
the FAA has proposed a framework for rules to guide the introduction of small UAS (those under 55 pounds), 
existing Federal Aviation Regulations do not allow for full integration of unmanned aircraft into the NAS.‘ In order 
to facilitate this integration, data supporting robust Detect and Avoid (DAA) and secure Command and Control (C2) 
capabilities need to be collected.° 

In support of the community needs, the National Aeronautics and Space Administration (NASA) under the UAS 
Integration in the NAS Project (hereafter referred to as UAS-NAS Project) is investigating and integrating 
technologies that are intended to reduce technical barriers related to the safety and operational challenges associated 
with enabling routine UAS access to the NAS.° The project is focusing on airspace integration procedures and 
performance standards to enable UAS integration in the air transportation system, covering DAA performance 
standards, C2 performance standards, and human systems integration. To support these research areas, the project 
also has an integrated test and evaluation focus, providing the infrastructure for simulating traffic and collecting 
data. The test environment is comprised of air traffic control workstations, constructive and virtual aircraft 
simulators, UAS ground control stations (GCS) and live manned and unmanned aircraft that, operating together, 
provide researchers with a relevant NAS environment to test unmanned systems. Working closely with the 
researchers, the simulation and flight-test development team designs an environment that meets the needs for each 
specific data collection requirement. 

This paper describes the objectives and requirements of the integrated flight tests planned by the UAS-NAS 
Project to collect the research data for the DAA, C2, and human systems focus areas. The designs and performance 
capabilities of the test infrastructure and data collection efforts are presented. 


II. Background 


A. UAS-NAS Project Overview 

With inputs from UAS stakeholders, including academia, government, and industry, the UAS-NAS Project was 
formulated to address the need for routine access to the global airspace for all classes of UAS. Based upon that need, 
the Project identified the following goal: To provide research findings to reduce technical barriers associated with 
integrating UAS into the NAS utilizing integrated system level tests in a relevant environment.® 

The project goal will be accomplished through the development of system-level integration of key concepts, 
technologies and/or procedures. In addition, these integrated capabilities will be demonstrated in an operationally 
relevant environment with the following objectives: 

e Report research findings (including validated data, algorithms, analysis, and recommendations) to 
support key decision makers in establishing policy, procedures, standards and regulations, enabling 
routine UAS access in the NAS. 

e Establish the infrastructure for the integrated test and evaluation environment for UAS Integration in 
the NAS simulations and flight demonstrations. 

The UAS-NAS Project research is divided into three main technical subprojects, each leading respective research 
areas: Separation Assurance/Sense and Avoid" Interoperability, Human Systems Integration, and Communication. 

Detect and Avoid (formally Sense and Avoid) is defined as “the capability of a UAS to remain well clear from 
and avoid collisions with, other airborne traffic”.’? The research conducted under this subproject focuses on the 
interoperability between two aspects of DAA, self-separation and collision avoidance. Collision avoidance is the 
maneuvering of one or more aircraft required to prevent an imminent near-midair collision. Self-separation is 
intended to address the ability of a pilot to “see and avoid” other aircraft with support from sensors and advisory 
algorithms without triggering collision avoidance maneuvers in either aircraft. In order to improve safe flight and 





* The Detect and Avoid nomenclature was adopted from the previously used Sense and Avoid after formulation of 
the Project, hence the old terminology usage here. 
2 
American Institute of Aeronautics and Astronautics 


interaction of unmanned aircraft with air traffic in the NAS, the human systems integration subproject researchers 
are investigating the display of necessary and sufficient information to the UAS pilot in the ground control station. 
This information includes the display of proximal aircraft and several levels of DAA maneuver advisories and alerts. 
The Communication subproject research includes the investigation of terrestrial based communication network that 
integrates line-of-sight ground station antennas to enable non-satellite based beyond line-of-sight control of 
unmanned aircraft from the ground. The Communications effort includes the development of prototype radios to test 
the terrestrial link performance characteristics and the C2 performance standards. 

Integrating each of these research subproject concepts together, the integrated test and evaluation team handles 
the system requirements gathering and development of the integrated test infrastructure. 


B. RTCA Minimum Operating Performance Standards (MOPS) 

RTCA was charted by the FAA to operate advisory committees that develop solutions to real-world air 
transportation problems.® In order to safely integrate the multitude of UAS platforms into non-segregated airspace, 
the FAA and UAS stakeholders have determined that both a robust DAA and a robust and secure C2 Data Link 
capability need to be established. In response, the FAA established the Unmanned Aircraft Systems Integration 
Office to support integration of UAS safely and efficiently into the NAS. In addition, RTCA formed Special 
Committee 228 to develop the Minimum Operational Performance Standards (MOPS) for DAA equipment, with 
emphasis in an initial phase of standards development on civil UAS equipped to operate into Class A airspace under 
IFR flight rules. The Operational Environment for the Phase 1 MOPS is the transitioning of a UAS to and from 
Class A or special use airspace, traversing Class D and E, and perhaps Class G airspace. A second phase of MOPS 
development is envisaged to specify DAA equipment to support extended UAS operations in Class D, E, and 
perhaps G, airspace. Moreover, the UAS Integration Office is working closely with the UAS community to develop 
the MOPS for the C2 Data Link. An initial phase of development will 
provide standards for the C2 Data Link using L-Band Terrestrial and 
C-Band Terrestrial data links. A second phase of MOPS development 
is envisaged to provide standards for the use of SatCom in multiple 
bands as a C2 Data Link to support UAS. NASA is a key member of 
RTCA SC-228 and is a primary contributor to the C2 and DAA 
MOPS. 


C. Flight Testing Overview 

To support the collection of data for the development of the RTCA 
Phase 1 MOPS, the UAS-NAS Project has planned a series of human 
in the loop simulations as well as two flight tests, Integrated Flight 
Test 1 and 2. The flight testing events are designed to enable 
collection of data in a realistic operating environment, including the 
inherent uncertainties of real winds and on board sensors. However, 
since the testing includes the flight of unmanned aircraft, which 
cannot presently fly in the NAS without restrictions and waivers from 
the FAA, the integrated test team developed a distributed environment 
that combines live, virtual, and constructive (or background) traffic 
and intercept scenario to promote the safe testing of the concepts and 
technologies 

While the live, virtual, and constructive (LVC) components*! of a 
test environment only encompass a portion of a full simulation or 
flight test, the test environment is widely known as an LVC, *!0!! 
Figure 1 shows the general usage of live, virtual and constructive 
assets contributing to the flight test environment. One of the 
significant aspects of the LVC environment is the support for Figure 1. LVC Environment Concept 
integration of distributed assets to enable usage of equipment without of Operations. An LVC environment 
the need for build-up of a local facility or deployment to a properly — promotes the integration of multiple live 

and virtual data sources. 


Constructive 








# A “constructive” simulation generally has no interactive human involvement in simulated conditions. Instead, 
scenarios unfold using rule-based decisions that control the interactions between simulated actors. “Virtual” 
simulations involve human participants operating simulated systems (e.g. a pilot flying a flight simulator). A “live” 
test environment involves human participants operating real systems. 
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equipped test range. Instead the distributed LVC environment promotes a test-in-place concept that allows 
researchers and technologies to utilize assets in situ. A more detailed discussion of the UAS-NAS Project’s LVC 
environment is described by Murphy, et. al.!* 

For the UAS-NAS Project flight-testing, data collection is divided into two distinct test configurations. The first 
involves a UAS aircraft equipped with representative cooperative (e.g. GPS based ADS-B transponder) and non- 
cooperative sensors (e.g. on board due regard radar) and flown with live intruder aircraft against a series of different 
scripted encounters to test the timing of the alerting from DAA collision avoidance, self-separation algorithms and 
interoperability with certified traffic collision avoidance systems (TCAS). All flights are conducted in restricted 
airspace in order to minimize risk. The second flight configuration integrates a surrogate UAS aircraft flown from a 
research ground control station equipped with pilot displays that provide advisories of potential conflicts and loss of 
separation. The ownship’$ (UAS) aircraft is equipped with cooperative and non-cooperative sensors as required for 
the test and flown in special use airspace. The location of the ownship aircraft is translated into a virtual air traffic 
control airspace populated with a mix of live and virtual background and intruder aircraft, providing a realistic 
environment. The pilot of the ownship aircraft is given a virtual “mission” to perform, while using the DAA 
advisories to maintain well clear of the live and virtual aircraft. 

In addition the UAS-NAS Project is planning a “Capstone” event. During this demonstration, the UAS aircraft 
will be flown in the NAS (with any necessary waivers from the FAA) to demonstrate the performance of the DAA 
technologies. It is not intended for the Capstone event to collect data supporting the MOPS, but provide an 
opportunity for the industry to witness the Project’s testing and provide outreach to the general public. 


III. Integrated Flight Test 1 Description 


The UAS-NAS Project requires several levels of flight test and simulation activities in order to collect the 
appropriate data to support validation of the DAA and C2 MOPS. As such, the Integrated Flight Test (IFT1), 
internally referred to as Flight Test 3, had six primary research goals: 

Validate results previously collected during project simulations with live data 

Validate performance models previously used during project simulations with live data 
Evaluate TCAS II/self-separation interoperability 

Test a fully integrated system in a relevant live test environment 

Collect data to inform final DAA and C2 MOPS 

Reduce risk for follow-on flight testing 


Se Ree 


These goals were derived from previous UAS-NAS Project simulations supporting an evidenced based build-up 
of the research. As described above, this flight test was divided into two distinct configurations (DAA Scripted 
Encounters and Full Mission), detailed in the sections below. 


A. Detect and Avoid Scripted Encounters Configuration 
The Scripted Encounters configuration generated data to evaluate the acceptability of the DAA alerts and 
advisories. This configuration had the following high-level objectives: 
e Validate closest point of approach prediction accuracy and self-separation alerting logic in realistic 
flight conditions 
e §=Validate self-separation trajectory model including maneuvers 
e Validate sensor and tracking models 
e Evaluate TCAS/self-separation interoperability 
o Ownship TCAS/self-separation interaction 
o Compatibility with intruder’s TCAS 
Evaluate DAA performance in multi-threat encounters 
Evaluate TCAS II as installed performance on a UAS 
Qualitatively evaluate pilot impression of self-separation advisories 
Inform final RTCA Phase 1 DAA and C2 MOPS 


In order to achieve the required test points, the Scripted Encounters configuration utilized NASA’s Ikhana MQ-9 
Predator-B aircraft as “ownship” aircraft. The Ikhana was equipped with a due regard radar, ADS-B, TCAS II, and a 
data fusion/tracker algorithm provided by Honeywell. Live intruders included a T-34C equipped with ADS-B and 





88 The ownship is the aircraft that contains the systems under test and evaluation. 
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TCAS I, and a King Air, equipped with ADS-B and 
TCAS II. The Ikhana sensor data was transmitted to 
the ground via a Ku-Band beyond line-of-sight link 
and sent to the DAA algorithms for analysis as shown 
in Figure 2. All test points were flown in the R-2515 
restricted airspace near NASA Armstrong. 

Three different DAA algorithms were tested (each 
during different test points). The first was the Conflict 
Prediction and Display System (CPDS) developed by 
General Atomics and TU Delft, which provided its 
own display to the pilot.’ CPDS shows the ownship 
with proximal traffic and represents advisories as 
vertical and horizontal warning zones. Encounters 
tested with the CPDS included Ikhana climb/Intruder 
descent, Ikhana with multiple simultaneous intruders 
(illustrated in Figure 3), and close encounters with an 
intruder to test the DAA interoperability with TCAS 
alerting. Test points included the DAA algorithm fed 
by individual and fused sensor data. 

The second was the JAVA Architecture for DAA 
Extensibility and Modeling (JADEM) from NASA 
Ames Research Center'*, which used the Vigilant 
Spirit Control Station’s (Vigilant Spirit) primary flight 
display to show advisories as a standalone unit next to 
the pilot. Vigilant Spirit is a fully implemented 
interface between a pilot in a GCS and an aircraft 
under control. It was developed by the Air Force 
Research Laboratory for flying UAS and is used as a 
test interface for the UAS-NAS Project.'> Tested 
encounters included “display scenarios” where the 
pilot of the Ikhana maneuvered the aircraft as directed 
by the DAA algorithm and “TCAS/self-separation 
interoperability scenarios” where the pilot does not 
maneuver the aircraft until the intruder’s TCAS has 
been alerted. 

The third was the Stratway+ algorithm from 
NASA Langley Research Center, which was originally 
developed to perform tactical resolution advisories for 
manned aircraft.'° Stratway+ presented its advisories 
on a standalone display next to the pilot via the Multi- 


Ikhana Ownship Live Intruder(s) 
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Figure 2. High-Level Architecture for the 
Scripted Encounters. The system diagram showing 
the flight assets and LVC system components used 
for the Scripted Encounter testing. Only one DAA 
algorithm was run during any given test point. 


90° maaan 









— 4 f500f 
soo ft 
= —_______-+ A&A 


MS9W 


Ownship 


Figure 3. Scripted Encounter Example. An example of 
multiple intruder encounter with an equipped UAS 
“ownship ”. 


Aircraft Control System (MACS) software.!’ Test points were designed to validate Closest Point of Approach 
predictions collected during earlier simulations using Stratway+.'® Specific encounters were also designed to operate 
on the edge of the alert threshold to collect data on the algorithm sensitivity to flight condition uncertainties. 
Additional test points included simultaneous multi-intruder encounters in both the vertical and horizontal domains 


and characterization of the due regard radar “edge” cases. 


B. Full Mission Configuration 


The Full Mission configuration was designed to support the evaluation of the display of the DAA self-separation 
alerts provided to the UAS pilot. This configuration had the following high-level objectives: 


e Evaluation of integrated self-separation algorithms, GCS traffic displays, and prototype C2 systems in a 


realistic environment 


e Evaluate the effect of self-separation alerting and guidance information on pilots' ability to maintain 


well clear 


Gather objective and subjective pilot data to evaluate/validate well-clear definition 


Analyze the performance of fourth generation C2 systems 
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Figure 4 depicts a simplified diagram of the LVC 
architecture used for the Full Mission configuration. The 
primary components included virtual air traffic control and 
constructive background traffic running at the NASA 
Ames Distributed Systems Research Laboratory, a live 
surrogate UAS aircraft controlled by the Vigilant Spirit at 
NASA Armstrong Research Ground Control Station 
Laboratory, DAA algorithms running in the NASA 
Armstrong LVC Laboratory, and live intruder aircraft. 

The surrogate UAS aircraft (henceforth known as the 
“ownship”) was flown under an IFR flight plan in 
scenarios with live and virtual aircraft. The constructive 
background aircraft, enabled through the LVC 
environment, consisted of IFR and _ VFR traffic. 
Confederate controllers set up interaction between the 
background aircraft and the ownship to ensure that the 
DAA system provided advisories to the pilot based on the 
definition of Well Clear Volume parameters. In order for 
“well clear” to be violated all of the following conditions 
must be met: 


Live Intruder(s) 


T-34C Ownship 
« — Na = 5 
= 


Background S 
Aircraft « R 
CNPC 
Ground 
Station 





Figure 4. High- -level LVC architecture used for 
the Full Mission configuration. Connectivity of the 
Background traffic and air traffic control clients 
running at NASA Ames with the live aircraft, DAA 
algorithm and the ground control station and NASA 
Armstrong. 


e = The horizontal closest point of approach or the current horizontal range is less than 0.8 NM 
e The time to horizontal closest point of approach is below 40 seconds 
e The time to co-altitude is below 40 seconds or the current vertical separation distance is below 500 ft. 


The scenario for this test was a UAS aircraft controlled by a GCS stationed in southern California, with the 
aircraft deployed to scout for active wildfires in the San Francisco Bay area (see Oakland airspace descriptor below). 
The JADEM software provided the DAA algorithm for the test. The ownship was a T-34C aircraft flown as a 
surrogate UAS aircraft from a GCS using Vigilant Spirit at NASA Armstrong. The T-34C was equipped with ADS- 
B to enable cooperative sensing of other ADS-B equipped aircraft. The T-34C and live intruder aircraft flew in 
special use airspace near NASA Armstrong (R-2515), with the coordinates of the virtual Oakland Center sector 
(combined sectors 40/41) translated to that airspace. : 
Constructive traffic and the confederate controllers were 
provided from a laboratory at NASA Ames interacting 
with the subject pilot and Vigilant Spirit via the 
distributed LVC system. Similar to the system used for 
the Scripted Encounters, the Full Mission system 
received data for the ownship and live intruder aircraft 
from the sensors on-board the T-34, sent to the ground 
via the C2 communication link. The virtual and live data 
were sent to and filtered by JADEM to determine which 
were candidates for processing by the algorithm and 
displayed to the pilot. 

The mix of live and virtual aircraft provided the pilot 
with a realistic air traffic environment. The fire-scouting 
mission was also intended to keep the pilot occupied to 
prevent focusing too much on intruder aircraft, hence a 
“Full Mission” environment. The controllers managed 
the traffic as test confederates, enabling intruder traffic 
to interact with the ownship. Figure 5 shows the 
depiction of the flight path of the ownship aircraft (solid 
line) during flight. The background shows the terrain of 
the actual airspace it was flying (i.e. R-2515), while the 
dashed line represents the relative position of the 
Oakland Center sector boundary in the virtual airspace 
of the scenario. In order to seamlessly combine the live 
and virtual traffic, the Oakland Center airspace (airways, 
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Figure 5. Overlay of Path of ‘Aieratt andl 
Airspace. The path of the aircraft (solid line) within 
the virtual Oakland Center airspace (dashed 
boundary) was translated to the R-2508 and R-2515 
airspace that surrounds NASA Armstrong. Inset: 
depiction of the actual Sector 40/41 boundary 
points for reference. 


sector boundaries) and virtual traffic were mapped 
into the R-2515 airspace. 

Each pilot flew two “Fire Mission” scenarios 
flying the same path, but with slightly different 
encounter geometries. In each scenario, the pilot was 
shown either a basic display of information or an 
enhanced display (shown in Figure 6). The basic 
information consisted of only the identification of the 
intruder based on the DAA alerts, while the enhanced 
display showed additional intruder symbols and 
maneuver advisories in the form of fly/no-fly bands. 
These have been coined “omni-bands” since they 
provide advisories for all viable flight headings. 


IV. Integrated Flight Test 1 Data 


In support of the Scripted Encounters, a total of 11 
Integrated Flight Test 1 flights were conducted : 
between 17 June 2015 and 24 July 2015. During those _‘ Figure 6. “Enhanced” display of DAA to the pilot. 
flights, 108 of the 120 planned encounters vignettes This shows the expanded concept for display of DAA 
were flown with Ikhana as the ownship. A total of — i#formation to a pilot, including the “basic” 

42.8 gigabytes of data were collected with a total of | information and additional maneuver advisories via the 
2376 data files. The Appendix provides a list of the | “omni-bands”, depicting clear of conflicting heading 
data collected and a detailed description of the data maneuvers 

can be found in the Data Management Plan.'? The data 

are under analysis by the DAA research teams and results will be published separately. 

The Full Mission configuration was run from 10-12 August 2015, with 3 pilots evaluating the display of DAA 
alerts in a realistic environment. The initial test plan called for a total of 10 test subjects, however significant 
problems with the data collection were documented during the preliminary integration testing and could not be 
resolved completely as execution of the flight test commenced. The most significant issue was with the command 
and control of the T-34C used as the surrogate ownship aircraft. During certain specific maneuvers, latencies 
between the time a maneuver was selected in the Vigilant Spirit and the time it was received and performed by the 
T-34C auto-pilot were recorded to be over 10 seconds. While observed on occasion during the check-out flights, this 
was an issue with the second and third test subjects and was a primary reason for ending the data collection early. 

In addition, significant data drop-out from the T-34C to the ground was observed. As seen in Figure 7, the 
telemetry from the ownship aircraft that 










: j : : 35.74 
was being transmitted via the C2 data link T-34C Track Plot 
would occasionally drop for up to 60 ! 
seconds at a time. This could have been 35.72 
accepted if these data-drop instances Missing 
. % Telemetry 
occurred only while the aircraft was not Data 
under a test encounter. However, several — 35.7 - 
occurrences while the aircraft was either z 
preparing to maneuver or maneuvering due e 
. 35.68 
to a DAA advisory were observed. ~N 
Ultimately, the value of the data being 
collected was questionable and the data 35:66 
collection efforts were postponed. It was ‘\ 
decided to move all remaining test points eh ascabiel 
for the Full Mission configuration to the 35.64 
-118.49 -118.48 -118.47 -118.46 -118.45 -118.44 


final integrated flight test to be conducted 


the following year. Longitude 


Figure 7. Display of T-34 Surrogate ground track. Aircraft position 
reports from the telemetry data shown as squares depict significant 
data drop for the ownship aircraft. 
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V. Integrated Flight Test 2 Description 


Integrated Flight Test 2 (IFT2) provides the researchers with an opportunity to expand on the data collected 
during the first flight tests. Following IFT1, additional scripted encounters with different aircraft performance and 
sensors will be conducted. The date for the IFT2 is being planned to ensure collection of data to support the 
validation of the final RTCA Phase 1 DAA MOPS. There are 9 primary objectives associated with this goal: 

e Evaluate the performance of the DAA system against cooperative and non-cooperative aircraft 
encounters 
e Evaluate the performance of an integrated DAA and Communications link that is representative of the C2 
MOPS latency 
e Evaluate UAS pilot performance in response to DAA maneuver guidance and alerting with live intruder 
encounters 
e Evaluate the effectiveness of the DAA system to enable timely coordination between UAS pilots and air 
traffic control 
Evaluate TCAS/self-separation interoperability 
Support validation of simulations used to develop the final Phase 1 DAA MOPS 
Characterize the performance of the flight test and simulation environment 
Demonstrate flight test and simulation environment readiness to support the Capstone flights/effort 


As with IFT1, this flight test series will have two primary configurations, the first will be a series of scripted 
encounters, supporting the collection of data to validate the interoperability of self-separation and collision 
avoidance algorithms. The second configuration will again include a full UAS pilot mission in a relevant test 
environment, including a realistic set of live and virtual traffic in the virtual airspace (though with a significantly 
increased number of encounters). For the Scripted Encounters, it is anticipated that the Ikhana will once again be 
ownship for the test. However, due to the problems with the latencies for control of the T-34C as a surrogate, a 
different aircraft may be obtained as ownship for the Full Mission configuration. Additional surrogate aircraft 
testing has been planned to ensure either the T-34C or the alternate aircraft meet the research requirements. 


VI. Capstone Description 


The Capstone demonstration is intended to provide a meaningful review of the technologies under research in 
the UAS-NAS Project. The purpose of the demonstration is to highlight the advancements in the state-of-the-art for 
safe UAS flight to industry and the general public. 

Two flights are planned for this demonstration. The first is a replication of the Full Mission configuration for the 
flight tests, but moved out to actual NAS airspace. Since the Project does not yet have an actual UAS aircraft that 
has both the C2 radios and sensors that provide data to the DAA algorithms, the T-34C surrogate will be flown to 
show how the integration between air and ground and pilot and aircraft can be integrated. The second flight attempts 
to stretch the bounds of Project technologies by flying the Ikhana aircraft in the NAS. The Ikhana will have on- 
board sensors and connection to a GCS (though through a SatCom and line of sight links instead of the prototype C2 
radios). This demonstration will include unrestricted airspace, featuring a flight from NASA Armstrong into Class E 
airspace to the Class D terminal airspace at Victorville and back. It is anticipated that this will require a waiver or 
exemption from the FAA. This is intended to show the safety of the technologies while providing a preview of the 
anticipated Phase 2 MOPS airspace. 


VII. Conclusions 


Despite the problems incurred during the Full Mission portion of the IFT1, significant data contributing to the 
Phase 1 DAA MOPS has been collected. Nearly all Scripted Encounter test points were run, with the data collected 
and archived by the UAS-NAS Project’s integrated test and evaluation team. While the Full Mission configuration 
experienced latency and surrogate control issues, the UAS-NAS project has documented each of the lessons learned 
and are applying those to reduce risk and ensure a successful execution of IFT2. 

Furthermore, the LVC test infrastructure, technologies, and techniques developed by the integrated test and 
evaluation team during conduct of the IFT1 are anticipated to provide not only a foundation for the conduct of IFT2, 
but for future manned and unmanned aviation research. As such, the development team is documenting the LVC 
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environment and its usage, as well as its interfaces to the client assets. This will be made available at the end of the 
UAS-NAS Project in September 2016. 

As the UAS-NAS Project prepares for its final Human in the Loop simulations and IFT2, the DAA, Human 
Systems, and C2 researchers are working closely with the RTCA SC-228 stakeholders to ensure the correct data are 
being collected moving towards successful Verification and Validation of the Phase 1 C2 and DAA MOPS. To 
support this effort and future analyses, all archived data will be made available for analysis by NASA research 


partners. 






















































































Appendix 
Listing and description of the data files captured during IFT1. 
System File Data Description Scripted Full 
Component Description Encounters | Mission 
LVC Gateway Comma Time and content of every message | Yes Yes 
(Data Logger) separated ASCII | passed through the LVC Gateway, 
data (CSV) ASCII format 
LVC Gateway Binary data file | Time and content of every message | Yes Yes 
(Data Collector) | (bin) passed through the LVC Gateway, 
binary format, used for playback 
JADEM CSV Ownship flight state data Yes Yes 
JADEM CSV Intruder state data (used for Yes Yes 
analysis) 
JADEM CSV Intruder state data (truth) Yes Yes 
JADEM CSV SAA threat results Yes Yes 
JADEM CSV SAA resolutions Yes Yes 
JADEM CSV SAA Release messages Yes Yes 
JADEM CSV Ownship constraints (from flight Yes Yes 
intent) 
JADEM CSV Encounter stats Yes Yes 
JADEM CSV Unresolved threats Yes Yes 
JADEM CSV Filtered conflicts (not analyzed) Yes Yes 
JADEM CSV Ownship path stretch metrics Yes Yes 
JADEM CSV Ownship resolution data Yes Yes 
JADEM CSV Ownship resolution attempts Yes Yes 
Stratway+ Custom log output | Flight State Yes No 
Stratway+ Custom log output | Customized Events Yes No 
Stratway+ Custom log output | Pilot Inputs and Flight Deck Events Yes No 
Stratway+ Custom log output | FMS Trajectories Yes No 
Stratway+ Custom log output | GCS Pilot Inputs and Flight Deck Yes No 
Events 
Stratway+ Custom log output | Closest Point of Approach Data Yes No 
Stratway+ Custom log output | Stratway Input Data Yes No 
Stratway+ Custom log output | Stratway Output Data Yes No 
Stratway+ Custom log output | Stratway Band Data Yes No 
CPDS bin Internal DAA algorithm data Yes No 
Sense and Custom log output | Ownship and intruder position Yes No 
Avoid data, ARINC 735B format 
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Processor 















































(SAAP) 
C90 Custom log output | Time and content for each Traffic Yes Yes 
TPA-100B Alert and Resolution Advisory 
generated by the TCAS system 
onboard the Intruder aircraft 
Thales ADS-B ASTERIX CAT21 | Aircraft position data Yes Yes 
format 
Vigilant Spirit Custom log output | Chat logs, Standard Tasks logs, No Yes 
Simulation Injections 
Vigilant Spirit Custom log output | Aircraft/UAS messages, telemetry | No Yes 
data from aircraft, route 
replanning data 
Vigilant Spirit GAZEDATA Eye Tracker Output File No Yes 
Smart Eye 
Camtasia Video file Movie of the UAS pilot’s primary | No yes 
flight display 
C2 Custom log output | Amount/Duration of voice No Yes 
communications between 
Pilot/Air Traffic Control 
C2 Custom log output | Latency of voice communications | No Yes 
Pilot/Air Traffic Control 
C2 Custom log output | Number of targets ADS-B & Radar | No Yes 
Latency of target information 
Air/Ground 
C2 Custom log output | Percentage of telemetry No Yes 
information successfully received 
from aircraft 
Latency of commands to aircraft 
Latency of telemetry from aircraft 
Survey Forms Excel Survey responses (to be No Yes 
spreadsheets transcribed into Excel) 
(from 
handwritten 
questionnaires) 
Survey Forms Excel Survey responses (to be No Yes 
spreadsheets transcribed into Excel) 
(from 
handwritten 
questionnaires) 
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